1. Field of the Invention
The present invention relates to a GFP (Generic Frame Procedure) frame transfer apparatus and GFP frame transfer method for transferring GFP frames, and more particularly, to a GFP frame transfer apparatus and GFP frame transfer method enabling performance monitoring of an end-to-end path in a GFP frame transfer.
2. Description of the Prior Art
With the rapid spread of the Internet, traffic of data systems such as IP (Internet Protocol) packets is expanding drastically in recent years. Realizing an efficient transfer of such data system traffic requires a network configuration and equipment designed in conformance with a conventional voice network such as a telephone network to be changed to a mode suitable for transferring data system traffic, above all, a mode suitable for transferring variable-length packets.
Conventionally, there is SONET/SDH (Synchronous Optical NETwork/Synchronous Digital Hierarchy) as a digital network for WAN (Wide Area Network). The SONET/SDH adopts a data structure suitable for accommodating voice signals, and with the expansion of data system traffic in recent years, technologies for efficient transfers of data system traffic on the SONET/SDH are under study.
One of such technologies is GFP (Generic Frame Procedure). This GFP is a general-purpose encapsulation technology or adaptation technology to accommodate variable-length packets with various protocols in an OTN (Optical Transport Network) using WDM (Wavelength Division Multiplexing) in addition to SONET/SDH. The technical content of the GFP is disclosed in a document “T1X1.5/2000-209 “Generic Framing Procedure (GFP) Specification” (hereinafter referred to as “document (1)”), by T1X1.5, one of the technical committees of the U.S.A. T1 Committee.
FIG. 1 shows a protocol stack of the GFP. The GFP consists of a GFP payload dependent sub-layer and a GFP payload independent sub-layer, and is a technology for accommodating various user protocols (user network protocols: Ethernet, HDLC, Token Ring, etc.) at edge nodes that interface with this user network and transferring these user protocols transparently.
FIG. 2 shows a basic frame format of the GFP. The GFP frame shown in FIG. 2 consists of a 4-byte core header field, a variable-length (4 to 65535 bytes) payload area field and a 4-byte FCS (Frame Check Sequencer) field.
As shown in FIG. 3, the above-described core header includes two PLI (PDU Length Indicator) fields each having two bytes and two cHECs (core Header Error Control) fields. The PLI indicates the length (number of bytes) of the above-described payload area and the cHEC indicates the result of a CRC16 calculation carried out on the PLI field and is intended for protecting integrity of the information in the core header.
As shown in FIG. 4, the payload area consists of a payload header and payload field (hereinafter simply referred to as “payload”). The payload header has a variable length of 4 to 64 bytes and the payload has a variable length of 0 to 65535 bytes. The payload in this payload area stores information to be transferred.
The FCS field is a 4-byte fixed length field shown in FIG. 5. The FCS field indicates the result of an FCS calculation (a kind of CRC32 calculation) conducted on the whole of the above-described payload area and used to protect the content of the payload area.
FIG. 6 illustrates the payload header in a GFP point-to-point frame (linear frame) (GFP frame used in a point-to-point connection (connection between two nodes)). The payload header of the linear frame has Type fields, tHEC (type Header Error Control) fields, DP (Destination Port) and SP (Source Port) as extension headers and eHEC (extension Header Error Control) fields. The Type indicates the type of a GFP frame format and the type of protocol of a higher layer of data stored in the payload field. The tHEC indicates the result of a CRC16 calculation on the Type field and is used to protect integrity of information in the Type field. The DP (destination port number) indicates one of 16 ports owned by the GFP edge node on the Egress side and indicates the output destination from the GFP edge node on the Egress side of a user packet stored in the relevant GFP frame. The SP (source port number) indicates one of 16 ports owned by the GFP edge node on the Ingress side and indicates the output destination from the GFP edge node on the Egress side of a user packet stored in the relevant GFP frame. The eHEC indicates the result of a CRC16 calculation carried out on the above-described extension header (Type and tHEC are not included) and is used to protect integrity of information in the extension header.
FIG. 7 illustrates the payload header in a GFP ring frame (GFP frame used in a ring connection). The payload header in the GFP ring frame includes Type fields, tHEC fields, a DP field, an SP field and eHEC fields as in the case of the payload header of the linear frame in FIG. 6 and further includes in its extension header (octet #5 to #20 in FIG. 7), DE (Discard Eligibility) as a Priority field and COS (Class Of Service), TTL (Time To Live) field, destination MAC (Destination Media Access Control) address (DST MAC) and source MAC (Source Media Access Control) address (SRC MAC). The above-described DE indicates priority in discarding the GFP frame. The specific method of use of COS (Class Of Service) is under study. The TTL is an 8-bit area indicating the remaining count of GFP transfers (GFP hops) and, for example, TTL=0 indicates that the GFP frame is terminated at the next GFP node. The destination MAC address is a 6-byte field indicating the address of the destination GFP node and the source MAC address is a 6-byte field indicating the address of the source GFP node.
In the GFP, the type of adaptation is specified by the Type field in the payload header and it is also possible to define information according to individual adaptations in the payload header. Adaptations assuming a point-to-point frame and ring frame are currently proposed as shown above these adaptations include features as shown below.                Point-to-point frame . . . Multiplexes streams of a plurality of user protocols at the SONET node of Ingress and transfers it to the SONET node of Egress. To identify the multiplexing of streams, port addresses (SP, DP) are provided in the payload header. Since no address information to identify the SONET nodes exists in the payload header, at the relay node routing cannot be performed in GFP frame units.        Ring frame . . . Constructs a ring similar to a shared bus on the topology of the SONET ring and provides the client with an Ethernet-like packet transfer. To provide a transfer within the ring, MAC addresses to identify SONET nodes are provided in the payload header.        
The adaptation method for accommodating Gigabit Ethernet, ESCON, Fiber Channel, FICON, etc. in the above-described GFP is reported in the above document (1) and document: “T1X1.5/2000-210, A Proposed Format for the GFP Type Field, October 2000” (hereinafter referred to as “document (2)”) and document “T1X1.5/2000-197, Transparent GFP Mappings For Fiber Channel and ESCON, October 2000” (hereinafter referred to as “document (3)”).
As a method for carrying out performance monitoring of a path to be set between two nodes in a ring connection, a method whereby a node, which has received a GFP frame, uses an FCS field check at the end of the GFP frame may be available. FIG. 8 illustrates a conventional target area for generating an FCS. As described above, the FCS field (4 bytes) added at the end of this GFP frame is the result of an FCS calculation (a kind of CRC32 calculation) carried out on the whole payload area and as a generating function G(X) in a CRC32 calculation, the following is used:G(X)=1+X+X2+X4+X5+X7+X8+X10+X11+X12+X16+X22+X23+X26+X32 
The fields of TTL and congestion control/priority (DE, COS) in the payload header of the ring frame are rewritten for every SONET node that terminates the GFP frame. Furthermore, in a “GFP bypass frame” that the present inventor et al. are proposing as a mode of the GFP frame in order to provide flexible routing, etc. in the GFP, some of labels in the payload header and control fields may be rewritten for every SONET node that terminates the GFP frame. That is, in many cases, in the SONET node, part of the payload header is updated and FCS recalculated. Therefore, it is possible to perform monitoring in ring units using the FCS field, but it is not possible to perform monitoring of the end-to-end path from the SONET node of Ingress to the SONET node of Egress. For example, when an error occurs in the data of the payload area, the node that has received this GFP frame can detect the error by an FCS field check, but if this node discards the GFP frame, the GFP frame and FCS are not transmitted to the subsequent nodes and it is impossible to perform performance monitoring of the above-described end-to-end path using the FCS field. Even if the node cannot discard the GFP frame containing the error, FCS is recalculated (re-created) and the GFP frame with the recalculated FCS added will be transmitted to the subsequent nodes, which causes the next node to judge the FCS check result as “correct”, making it impossible to realize performance monitoring of the end-to-end path using the FCS field.
The present invention is intended to solve the above-described problems and it is an object of the present invention to provide a GFP frame transfer apparatus and GFP frame transfer method capable of providing performance monitoring of an end-to-end path using the FCS field of a GFP frame in a GFP frame transfer.